Obtaining the Flow of Transaction:-  The transaction flows can be mapped into programs such that the flow of transaction will be created easily. The processing of the transactions is done inthe design phase. The overview section in design phase contain the details of the transaction flows. Detailed transaction flows are necessary to design the system's functional test.

 Transaction flows are similar to control flowgraphs  where the act of getting information can be more effective. Therefore, the bugs can be determined. The flow of transaction in design phase is done step by step such that the problems wouldn't arise and a bad design can be avoided.

 Transaction Flow Testing Strategies: Transaction flow is sequence of steps for a system to be tested. The transaction flow begins at the preliminary design and continues as the project progresses. The following testing strategies  has been taken.

1. Inspections: Inspections are the most cost effective quality processes  that  holds for testing. The process  include different phases such as "design phase, coding, testing, desk checking and debugging".

An inspection is a technique to detect errors by reading a group of code. This is often done by the developers or the programmers. A checklist is been compared with the code to  check errors. The duties of the programmer include,failures,

(1) Distributing the requirements, scheduling and inspecting the module.

(ii) Leading the session or module.

 (iii) Detecting the errors.

 (iv) Confirming that errors are corrected.

 Inspection is a methodology that humans can do and the computers can't. some of the example are,

 (1) Checking Syntax Errors: There would not be any syntax errors after inspection if humans do syntax

Checking.

(2) Referencing Program: The language processor cross check the undeclared variables, uninitialized values and be tables that are not been referred in the program. This is a tough job to be done by humans.

(3) Violating Rules: A program have some rules for declaring variables, labels, functions, subroutines and so  on. There may also be some conventions for the usage of memory. Hence, violation of these conventions (rules) is a form of syntax checking. A problem occurs for the language features that support automatic checking.  If the facilities for an automatic checking are not available then the person should check or inspect the code manually. The program is processed by examining  one convention at a time, rather than checking all  conventions simultaneously. It is a faster process to read the program for different conventions at different times.

(4) Comparison of Code: It is a mind-boggling task where the coding sheet is compared character by character to the code on keypunch cards.

(5)  Referencing Code: When a program is directly entered into a PC, the code is been referred or read by a programmer. It is an easier and faster way to check the errors for data structures, control flow and also for processing.

(6) Comparing Flowgraph: The flow graph is created from  the compiled code and compared to the design flowgraph. It's not an automatic task for comparing purpose.

(7)Sensitizing Path Inspection: The inspection should be path sensitizing i.e. the code cannot be forced to check bugs. Once the values of sensitizing paths have been found then necessary checking is done to every line of code involved in the control flow.

2. Reviews: Reviews are used to check the semantics (meaning) of a document. The quality of the documents can be examined and assured by eliminating the defects and mistakes from the documents. These inconsistencies can be found after the completion of document.

       The term review is a process involved with different techniques. It has the following phases in process.

(i)Review Planning: During planning phase, the documents in the software development process are assigned a review technique.

Every individual review has a review leader and a review team of its own. The document is read and checked from different points while planning the review.

(ii)Review Document Information: All necessary information is provided when the review team is formed. The information about the document is shared and reviewed. The reviewed document must be used to he decide if a particular statement is correct or wrong.

(iii)Preparing Review Meeting: The review meeting is  prepared by individual review team members. The inconsistencies and the defects are checked by the reviewers against the documents.

(iv)Objective of Review Meeting: The review meeting is handled bv a review leader. The review leader must ensure that the requirements of all the reviewers has met to find the defects and will be able to express their opinion without any fear.

(v)Taking Different Process: The review manager selects a different technique on the basis of the review results.

(vi)Review Scheduling: If the result of the first review was not acceptable, then another review will be organized by the review manager to correct the defects. Depending upon the review object, reviews can be classified as follows,

        (a) Feasibility Reviews: This review depends upon the logical flow of the document. Here, every unit in the document is feasible to test.

        (b)  Requirements Reviews: This review depends upon the requirements or attributes in the  document. A  system in this reviews can handle the structural limits of a transaction.

3.Walk Throughs: A walk through is an informal review method compared to the other types of reviews. It is a way of finding defects or problems or anomalies in the written documentation In the review meeting, scenarios are walked                   through i.e., the reviewers try to reveal defects and problems by asking questions.Walk through is a technique or a set of procedures to detect errors by reading a group of code. It is often used as part of testing cycle. Walk through has           a team similar to that of a reviewer team and consists of three people.

      (i) The first person plays the role of a secretary to record errors.

      (ii)The second person is similar to that of the a view leader (which handle the team).

      (iii)The third person plays the role of a tester to clear the defects.

During the meeting, the tester comes with a set of inputs to walk through the logic flow of the program. Each test case is individually executed and must be simple because the errors

found in the process of questioning the programmer are more than the errors found by the test cases.

4. Selection of Path for Transaction Flow Testing: The path selection for system testing that is based on transaction flows from the other unit tests that are based on control flowgraphs.  A longest path is taken to find the bugs in the module. The path is reviewed and the bugs are removed from all the

interfaces of the module after reviewing process is completed.

5. Act of Sensitization: The simple paths are easy to sensitize in transaction flows. It is the act of defining transaction. Some paths are difficult to sensitize and therefore these paths result in a bug transaction flows.

6. Measurement: During processing of modules, the information of the path taken for a transaction must be kept Since it plays an important role in the transaction flow testing.

7. Transaction Flow Databases: Every tester or programmer design his own unique database. The test databases in transaction flows are configuration sensitive. Here, every tester needs exclusive usage of system. Therefore, the test databases must be designed using configuration controlled and centrally administered systems.

8. Execution: From starting, the transaction flow testing is committed to test the execution part automatically.

There are four different types of testing that can be performed on a software system. They are as follows.

1. Unit testing

2. Component testing

3. Integration testing

4. System testing.

1. Unit Testing:-  A unit is the smallest piece of source code that can be tested. It is also known as a module which consists of several lines of code that are processed by a single programmer. The main purpose of performing unit testing is to reveal that a particular unit doesn't fulfill the specified functional requirements and also to show that the structural implementation is not similar to the expected structure designed.

Unit tests can be both static tests and dynamic tests. At  first. static tests are performed followed by the dynamic tests to check the test paths, boundaries and branches. Most of the unit tests are dynamic white box structural tests. These tests require either the execution of the software as a whole or parts of software. If a bug is revealed while performing the unit test, it is referred to as a unit bug.

2. Component testing:-  Component testing is nothing but black box functional testing. This testing is used to test a single component or a group of components. A component is created by integrating one or more modules to form a single Target component. A module is a component and the function it calls is also a component. Thus, a component can either be an individual module or whole integrated system. Component testing is performed when a component doesn't match with its functional specification or its implementation structure, defined during preliminary test design. If such problems occur while performing the tests, they are referred to as component bugs. These bugs are eliminated by using necessary debugging tools.

3. Integration Testing:-  Integration is a process of combining smaller components to produce larger components. Integration testing is performed when the individual components undergo component testing successfully. But when components are integrated, component testing is either incorrect or  inconsistent. It also ensures that each individual component behave as per the specifications that are defined during test design. The main purpose of integration testing is to be detect the inconsistencies between these components. For example, A and B are components that have gone through component testing successfully, but failed when integrated.

Some of the situations where inconsistency arises are as follows,

(i) When there is an improper call or return statement.

(ii) When there is an inconsistent standard for data validation.

(iii) When an inconsistent method is used for handling the data objects.

Integrated objects testing is a higher level component testing compared to integration testing. The objective of integration testing is to wipe out the difficulties that occur while integrating individual components.

Following are the steps to perform integration testing,

(i) A and B components undergo component testing.

(ii) A and B are integrated to perform integration  testing.

(iii) The new integrated component [A, B] finally undergoes component testing.

4. System Testing:-  System testing exposes bugs that are not resulted from the components or from the inconsistencies between the components. System testing is a black box functional testing to test the entire software system. It is performed to show the behavior of the system. System testing is done either on the whole system that is integrated or only on the important parts of a system. During the test design, it ensures the systems's behavior as per the requirements specification. Testing is performed for the following applications like accountability, security, performance, sensitivity, configuration, start-up and recovery.